After so many years, here in July 2024, I am finally hosting T-SQL Tuesday.

The challenge

One of the things I tend to do when I am working on a project is to think of myself over three time periods. The past, present and the future. The past version of me made lots of mistakes. Current Me is living through the mistakes Past Me made and does not want to repeat the same mistakes again and Future Me suffer.

As data professionals we know that what we do is crazy hard at times, and if you remember back in August of last year, Josephine Bush’s T-SQL Tuesday entry’s replies answered the question “what do all the database job titles actually mean?” There are more and more tasks and titles for what we do in the data field every year.

Hopefully this month I will get some people who got their start using SQL Server 1.0 on O/S 2, some in Data Science and even some who just started in tech pretty recently, maybe even starting with Microsoft Fabric. All replies are welcome because your mistakes are mostly non-unique.

So, what I want to know is:

What advice do you wish Current You could go back and give past you as you were starting your first data platform job?

Note: even with this fantastical scenario, let’s keep it realistic. No “invest in Microsoft, Apple, and Amazon” replies, but using the years, and perhaps even decades of experience we gather have, let’s hear it.

Your advice might be technical, like compiling isn’t testing, backups don’t always work. But I bet a lot of you have experiences that led to some major issue that younger you didn’t think of and failed in a way that your blog might help them avoid.

The rules

• Publish your post on Tuesday 9th of July, no matter what time zone you are in it is fine.
• Include the T-SQL Tuesday logo at the top of your post and link it back to this invitation post.
  • It would also be awesome to comment on this post with your link if possible (if you can’t leave a comment, email me!)
• If you’re on social media, share your post using #tsql2sday.

If you want to know more, check out the T-SQL Tuesday Rules of Engagement.

My example advice

Understand all the details of the problem before you release tables.

Too many times in my early career, I thought I knew how to solve the problem just after reading the abstract of what the customer wanted. Silly customer, why did you spend all that time describing what you needed, I have built a customer table! I know what the customer is saying when they say address. And so on.

Typically, assumptions were close, but in many ways that was a bigger problem than something that was very wrong because subtle issues often went unnoticed. In one of my first major systems I designed, only when the customer really started using the software in production did the issues really start showing up because what was thought to be a requirement very much wasn’t quite what was expected, and trouble ensued.

Note I specifically mentioned tables and not all code. Code changes easily, even database code. But structures are much harder to change, especially when the eyes of the customer are staring at you!